Взаимодействие с командой гиги

Написать куски наших пайплайнов в диприсече + написать
Ключевой проект Scientific Deep Research

0) Общий принцип: делаем pipeline средой RL + reward-shaping

Главная идея: конечная награда — качество финального отчёта (ваш judge +/или DR-bench метрики), но чтобы RL реально “попал” в ранние узлы, нужны промежуточные шейп-награды, которые коррелируют с финалом и быстро считаются.

Сквозной reward (пример)
(R = \alpha \cdot \text{ReportQuality} + \beta \cdot \text{CitationTrust} + \gamma \cdot \text{EvidenceCoverage} - \lambda \cdot \text{Cost})

Где:

• ReportQuality: например RACE-подобный скоринг (если вы используете DeepResearch Bench) (deepresearch-bench.github.io)

• CitationTrust / attribution: FACT-подобная метрика, либо автоматическая оценка атрибуции/цитат (ALCE / AttributionBench) (GitHub)

• EvidenceCoverage: покрытие ключевых субвопросов релевантными источниками

• Cost: токены, #search calls, latency, #источников, #параллельных микроисследователей

Ключевой feedback loop: в онлайне вы можете собирать трассы (brief → blueprint → queries → sources → findings → report) + оценки и дообучать (1) RM/judge и (2) policy.

---

1) clarify_with_user — “когда уточнять и что спросить”

Где улучшать

Провалы: (i) лишние уточнения, (ii) пропуск критических ограничений, (iii) вопросы не “развязывают” неоднозначность.

Гипотезы

• H1: RL-калибровка “need-clarification” уменьшит лишние уточнения без потери качества.

• H2: RL на качество уточняющего вопроса повысит downstream-retrieval (после ответа пользователя).

Эксперимент

Формулировка как contextual bandit:
Action: {ASK(q), PROCEED}. Reward: финальный скор − penalty за лишний turn.
Если ASK: оцениваем “полезность” вопроса через улучшение retrieval/качества отчёта после ответа.

Данные / бенчи

• ClariQ (offline + human-in-the-loop stage) (GitHub)

• Qulac (offline eval framework для clarifying questions) (GitHub)

• MIMICS (реальные веб-запросы + клики/ручные лейблы качества) (arXiv)

• TREC CAsT (конверсационный поиск, query rewriting/understanding) (ir-datasets.com)

Метрики

• Ask-rate vs Utility (ожидаемый прирост качества − стоимость turn)

• Delta-nDCG/Recall после ответа пользователя (на датасетах, где это возможно)

• Human/LLM-judge quality (ясность, конкретность, “resolves ambiguity”)

---

2) write_research_brief — “нормализация намерения без дрейфа”

Где улучшать

Провалы: теряются ограничения (“без экспериментов”), подмена цели (“сделай обзор” вместо “сравни”), добавление выдуманных требований.

Гипотезы

• H3: если бриф учится быть максимально верным и полным по ограничениям, то резко падает topic drift в blueprint и report.

• H4: reward за “constraint extraction” уменьшит число итераций/ретраев structured output.

Эксперимент

• Супервизия: бриф как структурированный JSON (goal, scope, exclusions, deliverables, constraints, evaluation style).

• RL-шейпинг:

  • • за полноту/верность ограничений (judge + простые регулярки/парсинг)

  • − за добавленные “галлюцинированные” требования

Данные

• Внутренние логи (самое ценное): пары {user request → “идеальный” brief от редактора/аналитика}.

• Для synthetic-подпитки: взять задачи из DeepResearch Bench и “перепаковать” в brief-формат (автоген) (deepresearch-bench.github.io)

• EXPERT-curated вопросы (как stress-set на ambiguity/precision требований): EXPERTQA (ACL Anthology)

Метрики

• Constraint-F1 (по заранее определённым слотам)

• Faithfulness score (LLM-judge + heuristic checks)

• Downstream: качество blueprint/report при фиксированном бюджете

---

3) create_report_blueprint — “декомпозиция + хорошие search hints”

Где улучшать

Провалы: задачи перекрываются, нет критических подзадач, поисковые хинты слишком общие/не-поисковые (“overview”, “paper”), плохая приоритизация.

Гипотезы

• H5: RL на “coverage-aware” декомпозицию увеличит полноту финального отчёта при том же лимите источников.

• H6: reward за “search-hint yield” (сколько релевантных источников нашлось) сильнее коррелирует с финалом, чем чисто текстовая оценка плана.

Эксперимент

1. Микро-метрика на каждый task: из хинтов строим search queries → считаем Recall@K по gold evidence (там где есть).

2. Макро-метрика: coverage субвопросов + минимальная избыточность.

Данные / бенчи

• Break (QDMR) — золотая декомпозиция вопросов (GitHub)

• HotpotQA — multi-hop + supporting facts (как прокси на “нужны несколько источников”) (hotpotqa.github.io)

• QASPER — вопросы по научным статьям + evidence (Hugging Face)

• Для retrieval-валидности хинтов: BEIR (много IR-задач и стандартные метрики) (GitHub)

Метрики

• Decomposition quality: coverage vs QDMR, redundancy rate

• Search-hint yield: Recall@k/nDCG@k по retrieval gold (где есть)

• Budget efficiency: качество / (#tasks, #queries, #sources)

---

4) execute_all_research — “поиск, остановка, извлечение фактов с цитатами”

Это самый “RL-вкусный” блок: тут есть действия, наблюдаемые сигналы и стоимость.

4A) Координатор: генерация поисковых запросов и отбор источников

Провалы: узкие/широкие запросы, повторяемость, выбор низкокачественных источников, плохая диверсификация.

Гипотезы

• H7: RL на query-diversity + evidence-recall поднимет покрытие без роста источников.

• H8: RL на source-ranking (переранжирование найденного) повысит citation-precision в отчёте.

Данные

• BEIR как универсальный retrieval-полигон (GitHub)

• SciFact: retrieval → rationale selection → label (идеально для “правильные источники/правильные предложения”) (GitHub)

• TREC-COVID / CORD-19 (научная литература, динамичный домен) (ir.nist.gov)

• Biomedical: BioASQ, PubMedQA (bioasq.org)

Метрики

• nDCG@10 / Recall@50/100

• Source quality proxy (домены/тип публикации) + “evidence density”

• Cost: #queries, latency, tokens

---

4B) Координатор: “рефлексия” и решение STOP/CONTINUE

Провалы: модель либо “копает бесконечно”, либо рано останавливается.

Гипотеза

• H9: обучаем stop-policy на предсказание “marginal utility” → получаем Pareto-фронт качество/стоимость.

Эксперимент

• Reward: (\Delta)качество (или (\Delta)coverage) за следующий поисковый шаг − λ * cost(step).

• Можно учить как policy-gradient или как value-model “стоит ли ещё искать”.

Бенчи

• Deep research агент-бенчи с фиксированным окружением (чтобы веб не “уплыл”): например среда с замороженными страницами (RetroSearch-подход) в Deep Research Bench от FutureSearch (arXiv)

Метрики

• Quality@Budget (AUC по budgets)

• Regret относительно oracle budget

---

4C) MicroResearchers / Extractor: атомарные findings + корректные цитаты

Провалы: “факты” не атомарны, не подтверждаются источником, цитата не туда, перефраз без опоры.

Гипотезы

• H10: fine-grained reward за поддержку каждым finding конкретным фрагментом источника резко снизит hallucination-rate.

• H11: reward за “evidence-span selection” улучшит точность цитирования (не просто URL, а правильное место/раздел).

Данные

• SciFact (claims + evidence sentences/rationales) (GitHub)

• QASPER (evidence параграфы/таблицы/фигуры) (Hugging Face)

• PubMedQA (abstract + conclusion, yes/no/maybe) (ACL Anthology)

• Корпуса для масштабного обучения “научного” экстрактора: S2ORC (GitHub)

Метрики

• Supported-claim precision: доля findings, которые entail’ятся источником (NLI/LLM-judge)

• Citation precision/recall: насколько цитаты действительно поддерживают утверждение (ALCE/AttributionBench-подобные метрики) (GitHub)

• Dedup quality: уникальные факты / всего фактов, конфликт-rate

---

5) final_report_generation — “сшивка отчёта: полнота, структура, цитаты”

Где улучшать

Провалы: слабая композиция секций, потеря важных findings, “красивая” вода, цитаты есть, но не “прикреплены” к утверждениям.

Гипотезы

• H12: RL на rubric-скоринг отчёта (по типу RACE/FACT) повышает качество без роста токенов/источников.

• H13: отдельный reward за “атрибуцию на уровне предложения” повышает доверие и снижает галлюцинации.

Эксперимент

• Основной: A/B на задачах DeepResearch Bench (или вашем internal bench) с одинаковым бюджетом источников.

• Дополнительно: train reward model на предпочтениях (pairwise) “какой отчёт лучше” (LLM-judge + human spot-checks).

Данные / бенчи

• DeepResearch Bench (PhD-level задачи, RACE/FACT-стиль оценивания) (deepresearch-bench.github.io)

• ALCE (citation evaluation benchmark) (GitHub)

• RAGBench (большой RAG-бенч, полезен как robustness-набор) (arXiv)

• Научная суммаризация как вспомогательная задача для “чистого” научного стиля: SciTLDR, ScisummNet, LongSumm, arXiv/PubMed summarization (GitHub)

Метрики

• Report rubric score (ваш judge +/или RACE/FACT)

• Citation quality: precision/coverage, доля “unsupported” предложений

• Структурная полнота: покрытие blueprint-секций и обязательных сравнений/таблиц

• Cost-aware: качество при фиксированных max_total_sources / tokens

---

6) Практичные feedback loops, которые “вкручиваются” прямо сейчас

1. Post-hoc blame assignment: если финальный отчёт провален по цитатам — штрафуем не весь трейс, а конкретные узлы (extractor/query-selector). Делается простым “диагностическим судьёй”: где впервые появилась неподдержанная claim.

2. Self-repair loop на узле (дешёвый и эффективный):

   • blueprint → “blueprint critic” → revision

   • findings → “citation verifier” → revision/допоиск
     Это даёт вам парные примеры (bad→good) для DPO/онлайн RL.

3. Budgeted search loop: учим stop-policy на реальных cost/quality кривых (качество отчёта vs #sources).

4. User-in-the-loop reward: в проде достаточно 1-2 клика (“полезно/не полезно”, “слишком поверхностно/слишком долго”) как bandit-сигнал — дальше он шейпится через вашу автоматическую оценку.

---

7) Мини-roadmap экспериментов для встречи с RL-командой

Если нужно “с чего начать” (макс. impact/сложность):

1. Extractor-RL на цитируемость (SciFact/QASPER + ALCE-style judge): обычно даёт самый быстрый выигрыш в доверии. (GitHub)

2. Blueprint-RL на coverage + hint-yield (Break + ваш internal bench): снижает “дырки” в отчётах. (GitHub)

3. Stop-policy (quality/cost Pareto) — экономия денег без потери качества. (arXiv)

4. Clarify bandit (ClariQ/Qulac/MIMICS): уменьшить friction и лишние вопросы. (GitHub)

---

Если хотите, я могу превратить это в конкретные карточки задач для RL-спринта (по 1 странице: цель, reward, датасет, метрики, риск/абляции), ориентируясь на ваши реальные ограничения (какая модель, сколько логов, можно ли хранить тексты источников, какие judge-модели, бюджет на human labels).

Приоритеты Q1 2026

Miro: https://miro.com/app/board/uXjVGIF1cx8=/

---

Лог встреч

2026-02-08 (ретроспектива)

Альберт — Научная премия Сбера:
- Созвон 05.02: заявки стартуют в ближайший понедельник, сбор до 30 апреля
- До 20 июня нужна экспертиза — к этому сроку готово заключение “🤖 4 эксперта”
- Задачи Альберта: распарсить PDF в заявке, починить sqlite для сводной базы, промпты по категориям, папка artifacts/v0.1 → версия 0.1
- Следующий шаг: ужесточить промпты (v0.2)

Альберт — База данных научных статей:
- Решили: самим написать ТЗ и искать ресурсы вместо медленных GigaEye
- Развернём всё на своём S3
- В понедельник Даня представит Альберту план по разработке базы данных

Данил Ш — SDR + Perelman:
- Первый драфт статьи по SDR накидан
- Дедлайн по черновикам статей — 16 февраля
- Приоритет на неделю: начать интеграцию Perelman + GigaScheme

DataChat:
- Договорились с Максом выкатить DataChat на платформу на грядущей неделе

Встреча с Ильёй Макаровым:
- Даня пришлёт документ о задаче по рецензенту-верификатору
- Илья (Иннополис + AIRI) пришлёт материалы по текущему рецензенту
- Даня пришлёт информацию о текущих проектах центра AI4S

ГОСТ Writer — новый проект:
- Созвон с Марией Пукальчик: обещала прислать примеры ТЗ → заполненный отчёт по ГОСТу
- Для УИИ важнее верификатор правильности заполнения (не писатель), т.к. нет статей на вход
- На след. неделе: найти шаблон по ГОСТу, прототип верификатора

---

2025-12-19
Команда гиги до 15 декабря хотели выкатить модель рефразер 3b, повышает качество на метриках

Raptor - инструмент для крутых ресичеров от стенфорда
Текущие инструменты гиги:
Сделать поисковый запрос
Прочитать в глубину
Поиск внутри страницы

Science Industry